QRZ! Ham Radio 3/QRZ Ham Radio Callsign Database - Volume 3.iso/digests/tcp/930256.txt

Internet Message Format | 1994-06-04 | 7KB

Date: Sun,  3 Oct 93 04:30:02 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V93 #256
To: tcp-group-digest


TCP-Group Digest            Sun,  3 Oct 93       Volume 93 : Issue  256

Today's Topics:
                       CW-ID waste of bandwidth
                            CW ID (2 msgs)
                    Raising the S/N ratio (2 msgs)

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Sun, 03 Oct 93 06:56:28 CET
From: BARRY TITMARSH <[e-mail]>
Subject: CW-ID waste of bandwidth
To: TCP-GROUP <[e-mail]>

I have been reading the newws and fully agree that the CW-ID rubbish
in the UK is a wast of bandwidth. In germany, there was a time that i caused
som harmonics. on a non ham band.. The Bundes Post simply sent me a letter
with a printout of the data connection i had at the time saying that my
transmitter was needing some maintanence. the callsigns were trapped on
a data analizer which is standard in ALL the radio Vans in Germany that
are used to trace All types of interferance, INCLUDEING radiation from
a PC !!! and PC's dont use CWID hi hi but it is still a simple thing to
pickup the PC's radiation from the VDU and reassemble the Picture
This is a std thing in the UK with TV dector vans for Hunting the NON license
holder,  So why use CWID'S ??
If you have 300 bd + 10/12 wpm cwid then there is more time spent CWIDing
that 300bd hf packeting.? on a busy channel.
I dont use CWID when im in the UK.. (dc0hk/gm8sau) bollox to it.
Barry.

------------------------------

Date: Sat, 2 Oct 1993 12:53:22 -0500 (CDT)
From: Steve Sampson <[e-mail]>
Subject: CW ID
To: [e-mail]

> [e-mail] says:
> Is it so bad ? As I understand it, we can use whatever (publicly documented)
> encoding scheme and modulation method we choose as long as the transmission
> is identified with a CW ident.

It's bad enough that the tradeoff you mention isn't worth it.  You should have
the right to experiment with data without having to use an 1860's modulation
scheme from the dark ages of choo-choo's.

> The loss in bandwidth due to a 5-second transmission every 15 minutes is not
> great, and as a result we have no mandatory requirement to use AX.25.

In 1200 and 2400 bps links the problem is that the CW is not properly decoded
by most DCD circuits, which results in collisions.  So while one station is
CW ID'ing others are colliding.  On 9600 and 56000 bps networks, CW ID of
5 seconds is equivelent to thousands of bytes lost, as most bursts would be
less than 1 second.

In the U.S. we can use any code we want, and no CW ID.  The restriction we have
is that you can't send third-party traffic using anything but AX.25.
---
Steve

------------------------------

Date: Sun, 3 Oct 1993 3:41:53 -0400 (EDT)
From: [e-mail] (Mike Bilow)
Subject: CW ID
To: [e-mail], [e-mail]

The problem of TNC DCD circuits not decoding the CW ID is not very serious.
Dumb DCD circuits, which are the default in most TNCs, will detect CW ID,
voice, and just about anything else.  Circuits which derive DCD from the
data stream clock are a problem, but this can be solved simply by sending
the CW ID using HDLC sync idle.

-- Mike

------------------------------

Date: Thu, 30 Sep 93 22:18:43 GMT
From: [e-mail] (Jonathan Naylor)
Subject: Raising the S/N ratio
To: [e-mail]

In an effort to raise the S/N ratio of the TCP-Group a little, here is an
observation on the behaviour of SMTP in NOS.

Is the bug still in the SMTP server and client that means that the
translation of lines with a dot at the beginning are not handled correctly.
RFC821 section 4.5.2 is the appropriate reference. The latest NOS source I
have is quite old and it cerainly does not handle these cases correctly.
Perhaps the maintainers of the various flavours of NOS would care to check
there code.

Would those who would like to expound there views on US politics please do so
elsewhere. If I want to read about US politics I read a P.J.O'Rourke book :-)
(see sig).

73's

Jonathan

+-------------------------------------+---------------------------------------+
| Internet: [e-mail]   | The three branches of Government:     |
| Amprnet:  [e-mail]      | Money, Television and Bullshit.       |
| BBS:      G4KLX @ GB7HMZ.GBR.EU     |           P.J.O'Rourke                |
+-------------------------------------+---------------------------------------+

------------------------------

Date: Sat, 02 Oct 1993 21:38:53 -0400
From: [e-mail] (Ashok Aiyar)
Subject: Raising the S/N ratio
To: [e-mail]

>In an effort to raise the S/N ratio of the TCP-Group a little, here is an
>observation on the behaviour of SMTP in NOS.
>
>Is the bug still in the SMTP server and client that means that the
>translation of lines with a dot at the beginning are not handled >correctly.

Yes, it appears to be still in there.  I am not aware of any NET/NOS which
handles the "." at the beginning of a line correctly, if I am interpreting
the RFC correctly.

If I compose a message with a line beginning with ".", my SMTP client
converts those lines to begin with "..".  It is my understanding the
receiving SMTP should remove the extra "." -- but I could well be mistaken.

If anyone is aware of an SMTP patch for this problem, I would appreciate
hearing about it.

Thanks,
Ashok
--
Ashok Aiyar                        Mail: [e-mail]
Department of Biochemistry                       Tel: [phone]
CWRU School of Medicine, Cleveland, Ohio         Fax: [phone]
MIME Enclosures OK

------------------------------

End of TCP-Group Digest V93 #256
******************************
******************************